1. Field of the Invention
The present invention relates to the object oriented software and in particular, it relates to designing and developing highly configurable software systems. More specifically, the present invention relates to a set of programming constructs and services that provide high levels of modularity, abstraction, dynamism and configurability.
2. Description of the Related Art
Supporting the creation of full-featured, easy to use, high performance, flexible, and reliable software that effectively and efficiently automates enterprise business practices is arguably the highest dollar value challenge for software development environments. Over the last few decades, software development environments have attempted to meet this challenge with increasingly sophisticated software models and the tools to support them. However they have not gotten better fast enough. Enterprise software problems have increased in complexity much faster than enterprise software solutions have increased in simplicity.
Modern enterprise software problems are generally more complex due to broader automation requirements, a changing user profile, and increased business practice diversity and dynamism. Additionally there is huge market pressure to reduce the costs and delivery schedules for adapting this more sophisticated enterprise software to meet specific, as opposed to generic business requirements. The technology industry so far has not responded with the appropriate software development environments to meet this new world's challenges.
1. Forces Driving Complexity
Previous enterprise software was expected to automate a single static business process. Today, enterprise software is expected to automate multiple, dynamic business processes. In addition, enterprise software is expected to provide seamless inter-operability and information access across these processes.
The users of enterprise applications have also changed. Previously, enterprise software was expected to maximize the productivity of inexpensive unskilled information-workers. Now the expectation is to maximize the productivity of expensive skilled knowledge-workers. This means enterprise software is expected to deliver complicated general unstructured information access and analysis.
As well, business practices in a modem enterprise have gotten more diverse and dynamic. The business world where enterprise software exists has changed dramatically because of more diversity in choice of business practices, more sophisticated and complicated business practices, more frequent mergers and acquisitions, greater expansion into global marketplaces, frequent governmental regulatory changes, more sophisticated continuous improvement BPR processes and increased economic uncertainty.
Enterprise software is not only meant to be usable in these complicated scenarios, but to drive them as a key player in these now normal enterprise processes.
2. Customer Requirements
These forces driving change in the business environment have a profound affect on the requirements of the enterprise software that supports these businesses. Current development methods are not well equipped to handle them.
Currently software is designed to meet the needs of potential customers by analyzing the generic requirements of a broad set of customers. These requirements then become input to the software development process where a version of the software that meets those requirements is generated. As new or changing requirements are captured from potential a or existing user base, a new version of the software is generated as quickly as possible to meet them.
While this procedure works adequately for limited, relatively static domains and customer profiles, it is a big problem for other domains and customer profiles. Customers often have a complex mixture of specific-requirements that generic requirements cannot capture. Further, their requirements may not be consistent across all of their users. As well, requirements may change faster than the vendor's development process can meet them. And some customer requirements may be so specific that it is not cost effective for the vendor to attempt to meet them.
This problem has been understood for a while within the industry. As a result, many customers develop their own software in-house because their vendors cannot solve these problems.
If the software vendor is not willing to accept the loss of sales to customers who are not well served by generic software, two approaches are applicable; static-customization, and dynamic-configuration.
Static customization is defined as a software package that is provided with a form of a development environment so that the customer's or vendor's developers can statically modify the package to match their requirements. This strategy includes the component style architectures built on standard object models such as OLE, Java beans etc. This approach has several drawbacks. The customer must either have in-house development expertise or hire hard to find and expensive consultants. It is slow and expensive and has to be repeated as requirements change. And lastly, when the vendor supplies upgrades to software, the customer's customizations often have to be performed over again.
Dynamic Configuration is defined as a software package that is provided with a broad and/or deep set of run-time options that can be set by the customer and that dynamically configure the software to meet customer specific requirements. This approach also has its drawbacks. Current software development environments do not adequately support the complex modeling problem presented by this high degree of run-time configurability because the software-models they are based on do not provide adequate solutions to the problems faced.
3. Limitations of Software Models
Current software models do not support solutions to the problems posed by a modem enterprise software system. They fall short in important features of modularity, abstraction, dynamism and configurability that are vital to application developers. This makes sense in that the traditional history of software environments is that they are first designed to meet the requirements of low-level system implementers and only for application level developers second. For example, both Java and C++ were first designed to solve system level problems. Software environments are typically implemented by people with low-level system expertise, and they naturally craft solutions for the problems that they face and understand.
In many ways, the entities that system designers model and the entities that application designers model are inherently different. System entities are short-lifetime, static and single-dimension. Application entities are long-lived, dynamic and multi-dimensional. System software deals with entities that have a lifetime that is linked to the process in which they are running. For instance, a memory-buffer is gone from the system's memory the second the process is stopped. In contrast, an application entity typically has a lifetime that is linked to real world external entities. They have a lifetime that is as long as the application needs to keep track of those real-world entities. An employee entity needs to be continuously managed even if the system that created it is modified. This aspect of persistence at the application level software leads to many new and different challenges as compared to system level software.
Another difference between system and application software is that application software faces run-time evolution. This is the natural and inescapable fact that real world persistent entities change their roles over time. An employee may be a contractor one day, and a full-time employee the next. A company may be bought by another and face different policies. System software typically has no concept of run-time evolution because the entities that they represent do not change significantly in their lifetimes. Application software has to deal with this problem constantly.
Still another difference between system and application software is that application software faces much more difficult design-time evolution. This is the also inescapable fact that software applications change over time, and the entities they create along the way are a persistent legacy for each new version of the software to manage. The software system design needs to be able to change, but still contain the same entities. System software as long it implements the same protocol or application programmer's interface (API), can store its internal memory buffers in any form it choses.
Unlike system software, application software has much more complicated multi-dimensional entities. The requirements of an employee type with all of the variations that customers require to meet their policies, and all of the contexts in which they are used, is substantively different from the system memory-buffer. A normal application entity is used in many processes, in different countries, different user-interface styles, by people of different expertise, and in many different business environments. This is a major multi-dimension challenge.
Current software models have a substantial list of shortcomings in more than a few areas. The current discussion of these shortcomings will focus on object-models because they are the current state of the art.
One of the challenges that an object system designer faces is that they want to modify the objects they have designed to achieve new objects that are different from the previous objects, but still act like the previous objects when they want them to. They also want to be able to re-use the code they wrote for these objects. This is commonly done by using inheritance hiearchies; but there is a large drawback to this technique: inheritance is static in nature. Once an object is created, it is restricted to one definition for its complete lifetime. This is not a problem for system software, but presents a substantial problem for application software. There are other techniques that can be used with object models such as delegation or parameterization; but since the object models do not support these techniques directly, they leave the software designer to provide these features for themselves. This demands unnecessary complex code with all of the inherent time and expense. What is needed is, a software model that supports a more dynamic object specialization technique.
In addition, these object modifications may be needed in more than one area simultaneously. Object models are one-dimensional. One cannot talk about dimensions of an object, because the current models do not directly support designs that divide up an object into multiple dimensions. For example in standard object models, an employee's compensation logic is not kept separate from its project-skills. Therefore these object models force the software designer to utilize informal techniques that break down when the number of dimensions becomes large. What is needed is, a software model that supports objects that are divided up into multiple dimensions in a formal sense so they do not have to rely on hard to manage, ad-hoc and unstructured techniques.
Object models have little or no concept of process modeling; the modeling of how groups of objects are used to implement the business operations they were designed to support. In standard object models, process models are constructed with a preponderance of code external to the group of objects in non-re-usable and complex manners. What is needed is, a software model that supports process models that are contained inside the object so they are re-usable and can be managed as part of the object.
Finally the history of software models is the history of the increased application of two techniques: modularity and abstraction. Modularity is the dividing of a large problem into multiple easier to handle smaller ones. Abstraction is the separation of what is desired, from how it is implemented in the specification of an object. But object models have inherent flaws in modularity and abstraction. A substantial amount of the code, associated with an object's usage that could be internal to the object, must be implemented in multiple external objects. At best this causes dramatically reduced re-use. At worst, it causes the real code for an object, which is the combination of what is rightly inside, and what ended up outside, to be confusing and fragile. This is a major flaw just where object models should be strongest. What is needed, is a software model that permits all the code associated with an object to be placed directly in that object. This would allow the software designer to achieve higher modularity and abstraction.